Internet Protocol (IP) networks are required to route several types of content, with differing requirements of reliability, speed, latency, scaling and bandwidth utilisation. Increasingly, such networks are being used to deliver video content, both point-to-point and also point-to-multipoint (analogous to broadcast television, where there may be large numbers of clients consuming the same television programme). In the latter case, an important goal in many situations is to reduce the number of simultaneous streams that need to be transmitted: for example, a strategy whereby a sender transmits a discrete stream of content for every client (unicast) is very inefficient in terms of network utilisation and computational resources. Additionally, in this approach, the sender needs to maintain knowledge of all the clients which are consuming the content at any time, since a unique IP stream must be generated for each client.
Several solutions have been proposed or adopted to address these issues. Streaming proxies can help in the unicast case, in that they can accept an input stream, and replicate it to multiple clients, thus removing the need for the content server to maintain a record of active clients, and also allowing the streaming proxy to be located topologically closer to the clients (i.e. closer in terms of network nodes and links), and possibly “better” located to them in terms of factors such as the cost of using the necessary links, or in terms of the likely network performance thereon (e.g. round-trip time (RTT) or delay, jitter, reliability, etc.). In situations requiring higher numbers of clients, various forms of Content Delivery Networks (CDNs) and/or multicast (IP-layer, or higher-level) are used (BBC “iPlayer”, etc.). A typical CDN is a system that can serve content from multiple servers at various locations, in order to spread the system load, and to dynamically adjust various parameters such as routing in response to changing demand and possible other network issues.
These approaches cater well for content that changes relatively slowly (i.e. content is generally added and deleted perhaps a few times a day), and for situations where clients join and leave at any time. They generally assume a network topology that is either fixed or varying slowly. Techniques based on Application-Layer Multicast (ALM) allow extra intelligence to be added in order to manage the stream distribution better—this becomes more important in cases where both the sources and clients may join and/or leave frequently.
In cases where two (or more) parties are taking part in a video-enabled chat, the networking requirements change, in that there is no longer necessarily a ‘producer’ and ‘consumer(s)’ of the video; all parties may essentially be peers. This situation places additional demands on the network topology when large numbers of separate n-way video sessions are required, as may be the case in relation to a multi-party video-enabled discussion forum, for example.
Many existing techniques (such as video-conferencing technologies, for example) assume that a network topology is generated and/or dimensioned before or at the start of a call or session, and that this will fundamentally not change throughout the call. Changes are generally limited to adding or removing streams as clients join or leave. Other changes may be for example to switch from multicast to unicast (perhaps with some local caching) if a client needs to pause the feed, for example.
Additionally, traditional networks have generally been designed with resilience and reliability as fundamental requirements. These have generally been addressed by adding link redundancy, which generally works well for IP-based protocols. However, real-time video communication with relatively high bandwidth streams places demands on network performance which can currently add significant cost if a consistently high quality of experience (QoE) is required.